The DCS format made a lot of sense five years ago. Does it still work today?
Bob Schaffel and Chuck Weger
DESKtop Media
These days it's easy to believe that the basics of desktop prepress technology have been conquered -- now we can go on with the bold, the beautiful, the emerging. Then along comes a crop of newly emboldened, highly creative people to whom the phrase don't do that sounds like some expression in the Klingon language -- it doesn't mean anything. Common wisdom about what works is challenged in the name of creating product differentiation, innovative design, and efficient production. Unfortunately, just because something can be done doesn't mean it should be -- at least not without understanding the implications and consequences.
Recent experience suggests that we'd better revisit that time-honored technique, Desktop Color Separation (DCS). Why? Because emerging methods of production may require you to think twice before using it. DCS was first implemented by CyberResearch for its CyberChrome color separations, back when Adobe Photoshop was still in development by the Knoll brothers. When DCS was created, there were no CMYK TIFFs. DCS allows the placement of a master file (in EPS format) that contains the following: an image preview for on-screen viewing, low-resolution PostScript data for composite proofing, and links to four preseparated high-resolution files (also EPS) containing CMYK data.
DCS was slow to take off: The CyberChrome page descriptions required postprocessing to swap in the high-resolution data for making final separations. But DCS gained popularity when Photoshop was imbued with DCS functionality and when QuarkXPress (version 2.0a, if memory serves) gained the ability to swap in high-resolution data for separations.
In many production environments, DCS makes an efficient file-format choice. The master file contains only low-resolution output data. Because this low-resolution file is small, workstations on which design and proofing -- but not separations -- occur can be equipped with lower-capacity hard drives. Less data means faster processing and lighter network traffic loads. It's hard to argue with these benefits, so many companies have designed their file-handling procedures around the DCS format.
The problem now is that many companies are attempting to implement production workflows to permit the republishing of content on alternative media. Although material printed on a traditional press may still be the primary (and most commercially viable) product, the World Wide Web, CD-ROM, interactive cable, and digital printing presses now present additional opportunities to extend the market for the product. All of these alternatives have their own particular image requirements -- ones that may make it difficult to convert DCS images into formats they can use.
To DCS and Back -- Again
Take printing on a digital press such as the Xeikon as one example. This device is an attractive choice for printing on demand or producing custom material. Digital presses do not use color separations -- they require composite data, much as any laser printer does. Thus DCS images must either be converted back to a composite file or handled with something along the lines of Total Integration's SmartXT, a QuarkXPress XTension that automates the conversion of a DCS file to a composite one at print time.
Either way, a time penalty is exacted during the conversion. For jobs that contain only a few images, that delay is tolerable. But for textbooks, catalogs, and other documents that contain many images, it's economically impractical to convert everything -- it simply takes too long to fit within most production deadlines. Something has to give. Either more time has to be allotted (and more expense if you're asking your service provider to do the work), or you must be prepared to submit composite images for the output.
Additionally, problems occur when DCS images are included in pages that may themselves be turned into DCS files. (A real-world example is the teacher's edition of a textbook that uses student-edition pages as illustrations.) Attempting to create separations from nested DCS files will fail, because the nested links to the high-resolution data will be overlooked. There may also be serious problems with attempts to do page impositions when DCS files are nested.
Here are some "don't do that" tips for using DCS:
* Don't submit DCS files when composites are required for output.
* Don't nest DCS files within other DCS files.
* Don't rename DCS files after they have been created, because links to the high-resolution data depend on the filenames.
* Don't use the DCS format when your final output is a computer screen -- DCS files are CMYK, but the monitor is RGB -- until we have more-robust color-management systems, that is.
* Don't forget to discuss with your service provider the new ideas you have for enhancing your workflow. Although your ideas may make sense in your own environment, there may be compelling reasons down the production line not to implement them. Remember, you may be fluent in Klingon, but the rest of us have to translate it into PostScript.
Bob Schaffel is emerging-technologies consultant for R. R. Donnelley & Sons. Chuck Weger is a graphic-arts consultant and a partner in Genex Media, a company specializing in new media and Web design.
